Subject: RE: URGENT: NEED YOUR VOTE: DLSw Multicast Spec

From: Stephane St-Hilaire <[email-masked]>
Date: Tue, 08 Oct 96 09:10:00 PDT

I have no problems with this direction (I approve).

Stephane St-Hilaire
Eicon Technology

 ----------
From:  aiw-dlsw-scalability
Sent:  Monday, October 07, 1996 8:39 PM
To:  stephanh
Subject:  URGENT: NEED YOUR VOTE: DLSw Multicast Spec

I didn't get any responses from anyone on this...I'm assuming
nobody got it (of course).  Could ONE representative from
each member organization please let me know whether they
approve or disapprove of this direction?

Thanks, Dave

To: aiw-dlsw-scalability  @ listproc.raleigh.ibm.com @ ugate
cc:
From: David Bryant/HQ/3Com
Date: Wednesday  October 2, 1996 04:33 PM
Subject: DLSw Multicast Spec
 --------------------------------------------------------------------------  
 -----
 --------------------------------------------------------------------------  
 -----
 ----------------------------------
Guys -

Before I write anything down, let me see if I can gain concensus.

Seems we're all in relative agreement on all the nit issues
and the main sticking point is what to do about single tunnel
bring-up.   Here's my analysis of the situation:

 - I think single tunnel bring up is an important extension
that should be part of the standard.

 - I think it's highly desirable to come out with it in the
initial spec.  But either way, we need to accomodate migration
and interoperability issues with existing dual tunnel activation
ala RFC 1795.

 - It appears as though the use of a different destination
port number (2067)provides an adequate means for providing the
migration path.

 - I think there are two paths single tunnel can go:
 Use TCP to resolve race conditions
 Add race condition state machines into DLSw

 - Either way, I think we'll either encounter issues or spend
time developing state machines and we won't stay on schedule for
a November CP date.

So given this analysis of the situation, here's my suggestion:

I suggest we complete the spec stating dual tunnel bring-up ala
RFC 1795.  We follow-up with an optional enhancement for single
tunnel bring-up in the next iteration. Likely, we'll base the
enhancement on the port 2067 thing, thus allowing smooth migration
and interoperability.  This way, will give ourselves some more
time to work out the appropriate single-tunnel solution.

All those who object,let me know asap... so I can complete writing
and keep this thing moving. If you agree, please post agreement
asap as well.  This way I'll know people have read it and agree.

Thanks, Dave

---

From: Krzysiek Perycz <[email-masked]>
Date: Tue, 08 Oct 96 09:51:37 EST

Dave,
     I agree with your suggestions.
     Krzysiek Perycz
     CrossComm Corp.

______________________________ Reply Separator _________________________________
Subject: URGENT: NEED YOUR VOTE: DLSw Multicast Spec
Author:  David.Bryant/HQ/[email-masked] at inet
Date:    10/7/96 8:39 PM

Thanks, Dave

To: aiw-dlsw-scalability  @ listproc.raleigh.ibm.com @ ugate 
cc:
From: David Bryant/HQ/3Com
Date: Wednesday  October 2, 1996 04:33 PM 
Subject: DLSw Multicast Spec
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
------------------------------
Guys -

     

     

     
I suggest we complete the spec stating dual tunnel bring-up ala RFC 
1795.  We follow-up with an optional enhancement for single tunnel 
bring-up in the next iteration. Likely, we'll base the enhancement 
on the port 2067 thing, thus allowing smooth migration and 
interoperability.  This way, will give ourselves some more time to 
work out the appropriate single-tunnel solution.

Thanks, Dave

---

From: Scott Bales <[email-masked]>
Date: Tue, 8 Oct 1996 10:30:24 -0400

In order to keep on schedule for V1.1, this is acceptable.  We will need to
revisit use of single-pipe bringup for Multicast/Unicast Peer-on-demand for
the V1.2 spec (or whenever we finalize single-pipe bringup plans).

 - Scott Bales, Cisco systems

-->  From [email-masked]  Mon Oct  7 20:39:37 1996
-->  Date: Mon, 7 Oct 1996 20:39:32 -0400
-->  Reply-To: [email-masked]
-->  Originator: [email-masked]
-->  Sender: [email-masked]
-->  From: David.Bryant/HQ/[email-masked]
-->  To: [email-masked]
-->  Subject: URGENT: NEED YOUR VOTE: DLSw Multicast Spec
-->  X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas
-->  X-Comment:  DLSw scalability issues
-->  Content-Length: 2240
-->  
-->  I didn't get any responses from anyone on this...I'm assuming 
-->  nobody got it (of course).  Could ONE representative from 
-->  each member organization please let me know whether they 
-->  approve or disapprove of this direction?
-->  
-->  Thanks, Dave
-->  
-->  
-->  To: aiw-dlsw-scalability  @ listproc.raleigh.ibm.com @ ugate
-->  cc:  
-->  From: David Bryant/HQ/3Com    
-->  Date: Wednesday  October 2, 1996 04:33 PM
-->  Subject: DLSw Multicast Spec
-->  ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
-->  Guys - 
-->  
-->  Before I write anything down, let me see if I can gain concensus.
-->  
-->  Seems we're all in relative agreement on all the nit issues 
-->  and the main sticking point is what to do about single tunnel 
-->  bring-up.   Here's my analysis of the situation:
-->  
-->  - I think single tunnel bring up is an important extension 
-->  that should be part of the standard. 
-->  
-->  - I think it's highly desirable to come out with it in the 
-->  initial spec.  But either way, we need to accomodate migration 
-->  and interoperability issues with existing dual tunnel activation
-->  ala RFC 1795.
-->  
-->  - It appears as though the use of a different destination 
-->  port number (2067)provides an adequate means for providing the 
-->  migration path.
-->  
-->  - I think there are two paths single tunnel can go: 
-->   Use TCP to resolve race conditions
-->   Add race condition state machines into DLSw
-->  
-->  - Either way, I think we'll either encounter issues or spend
-->  time developing state machines and we won't stay on schedule for
-->  a November CP date.
-->  
-->  So given this analysis of the situation, here's my suggestion:
-->  
-->  I suggest we complete the spec stating dual tunnel bring-up ala
-->  RFC 1795.  We follow-up with an optional enhancement for single
-->  tunnel bring-up in the next iteration. Likely, we'll base the 
-->  enhancement on the port 2067 thing, thus allowing smooth migration
-->  and interoperability.  This way, will give ourselves some more
-->  time to work out the appropriate single-tunnel solution.
-->  
-->  All those who object,let me know asap... so I can complete writing 
-->  and keep this thing moving. If you agree, please post agreement 
-->  asap as well.  This way I'll know people have read it and agree.
-->  
-->  Thanks, Dave
-->  
-->  
-->  
-->    
-->  
-->  
-->  
-->    
-->  
-->